1 




United States Patent and Trademark Office 




DEPARTMENT OF COMMERCE 
Trademark Office 
FOR PATENTS 

inia 22313-1450 



APPLICATION NO. 


FILING DATE 


FIRST NAMED INVENTOR 


ATTORNEY DOCKET NO. 


CONFIRMATION NO. 


09/843,429 


04/25/2001 


Anita B. Marsh 


06269-030001 


8544 



26211 7590 10/23/2006 

FISH & RICHARDSON P.C. 
P.O.BOX 1022 

MINNEAPOLIS, MN 55440-1022 



EXAMINER 



VU, TUAN A 



ART UNIT 



PAPER NUMBER 



2193 

DATE MAILED: 10/23/2006 



Please find below and/or attached an Office communication concerning this application or proceeding. 



PTO-90C (Rev. 10/03) 



Office Action Summary 

m. m m a m a a. a ma*, m. am^^am m * ■ • * ^ m 


Application No. 

09/843,429 


Applicant(s) 

MARSH ET AL. 


Fvaminer 

LAQII 111 ICI 

Tuan A. Vu 


Art Unit 

2193 





The MAILING DATE of this communication appears on the cover sheet with the correspondence address » 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) OR THIRTY (30) DAYS, 
WHICHEVER IS LONGER, FROM THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1.136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 1 33). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1.704(b). 

Status 

1 )[X] Responsive to communication(s) filed on 03 July 2006 , 
2a)E3 This action is FINAL. 2b)D This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 1 1 , 453 O.G. 213. 

Disposition of Claims 

4) [3 Claim(s) 1,2 and 4-35 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) EI Claim(s) 1-2. 4-35 is/are rejected. 

7) D Claim(s) is/are objected to. 

8) D Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) D The specification is objected to by the Examiner. 

10)D The drawing(s) filed on is/are: a)D accepted or b)D objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1.85(a). 

Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 
1 1 )□ The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. § 119 

12)D Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 
a)D All b)D Some * c)D None of: 

1 Certified copies of the priority documents have been received. 

2. Q Certified copies of the priority documents have been received in Application No. . 

3. D Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 



Attach ment(s) 

1) Q Notice of References Cited (PTO-892) 

2) |_J Notice of Draftsperson's Patent Drawing Review (PTO-948) 

3) LJ Information Disclosure Statement(s) (PTO/SB/08) 

Paper No(s)/Mail Date . 



4) O Interview Summary (PTO-413) 
Paper No(s)/Mail Date. . 



5) 
6) 



Notice of Informal Patent Application 
Other: . 



U.S. Patent and Trademark Office 
PTOL-326 (Rev. 08-06) 



Office Action Summary 



Part of Paper No./Mail Date 20061005 



Application/Control Number: 09/843,429 Page 2 

Art Unit: 2193 

DETAILED ACTION 

1 . This action is responsive to the Applicant's response filed 7/3/2006. 

As indicated in Applicant's response, claims 1, 15, 23 have been amended; and claim 3 
removed. Claims 1-2, 4-35 are pending in the office action. 

Claim Rejections - 35 USC § 101 

2. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

3. Claims 15-22 and 35 are rejected under 35 U.S.C. 101 because the claimed invention is 
directed to non- statutory subject matter. 

Claim 15 recites a system comprising a repository of components, a call controller, and a 
gateway under the control of the controller to download call service components and to support 
telecommunications traffic. As garnered from reading the specifications, the repository (i.e. 
repository 66) can be a file system directory or a database —thus not a machine; the controller 
can be a Softswitch ( see pg. 6), thus also software implemented. Further, there is no explicit 
teaching to put forth that the media gateway (i.e. gateway 24 - as noted in the specifications) is 
necessarily a physical device or a tangible computer because according to broad interpretation by 
one skill in the art at the time the invention was made both gateway and controller can be 
software implemented. The claim does not provide reasonable teaching to enable the 
interpretation that the above components are tangible apparatuses. Absent any tangible support 
for embodying the components recited in this system claim, the claim cannot yield a tangible 
result from this so-recited system. The claim amounts to a mere abstract, non-practical idea 
according to the following requirement. 
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The Federal Circuit has recently applied the practical application test in determining whether the claimed 
subject matter is statutory under 35 U.S.C. § 101. The practical application test requires that a " useful, 
concrete, and tangible result" be accomplished. An "abstract idea" when practically applied is eligible for a 
patent. As a consequence, an invention, which is eligible for patenting under 35 U.S.C. § 101, is in the 
"useful arts" when it is a machine, manufacture, process or composition of matter, which produces a 
concrete, tangible, and useful result. The test for practical application is thus to determine whether the 
claimed invention produces a "useful, concrete and tangible result". 

Hence, the claim is rejected for leading to a non-statutory subject matter; the dependent 
claims 16-22 are also rejected for not remedying to the non-practical concept deficiency of the 
base claim. 

Claim 35 recites a system comprising a network carrier, media gateways, a controller and 
a management system. The specifications do not provide clear teaching showing that those 
components are tangible hardware devices, or articles of manufacture because for one skill in the 
art at the time of the invention all of them can be perceived as being software implemented, i.e. 
being supported or embodied by no tangible hardware or device/media. Absent any tangible 
support for embodying the components recited in this system claim, the claim cannot be 
construed as being able to yield a tangible result. The claim amounts to a mere abstract, non- 
practical idea according to the above Practical Application Test requirement. 

It is strongly recommended that Applicant provide clarification as to why the recited 
system components are necessarily implemented in hardware based on the specifications for the 
rejection thus set forth to be withdrawn. 

Claim Objections 

4. Claims 1-2, 4-35 are objected to because of the following informalities: the claims 1,15, 
23, 34-35 include 'dynamically removing the call component from the call controller 5 . In the 
Specifications, there is mention of a component possibly being removed - i.e. can be removed ~ 
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( Summary, pg. 2, 2 para; pg. 10, top para) when a service is no longer needed. There appears 
to be insufficient teaching at to the timeframe in which the controller determines whether a 
component is no longer needed, and the use of this 'dynamically 5 term (even in the 
Specifications) would sound improper; that is, how the above decision to remove would coexist 
with this 'removing' act recited as necessarily done 'dynamically' in the runtime context of a call 
being still on with the component still needed. There is no clear and deliberate definition of this 
term 'dynamically' in the disclosure to ascertain about the dynamic degree or timeframe of this 
limitation. For one skill in the art, the disclosed determination that a service is no longer needed 
reasonably enforces a portion of time clearly subsequent to that during which the call is still 
being serviced (in which component is still needed). Based upon this, the above disclosure on 
that need determination (i.e. 'when no longer needed' phrase) will invalidate the usage of what is 
recited as 'dynamically removing'. Besides, the Specifications recite 'can be removed' (see pg. 
10, top para), denoting thereby that an absolute removal (of components 42, 44) during the 
above call servicing or afterwards — is not a certainty. The language expressed as 'dynamically 
removing' in light of the above has to be semantically commensurate with the extent to which 
the original disclosure allows, for this language impropriety is short of a deficiency termed as 
lack of definiteness in the claimed subject matter. This limitation will be treated as 
'dynamically' removing some call processing items in the runtime of the call service, for 
example removing the call connection as more clearly described in the Specifications (see pg. 11, 
bottom, pg. 12, top). 

Dependent claims from the above base claims are also objected for lack of support to this 
language impropriety. 



Application/Control Number: 09/843,429 Page 5 

Art Unit: 2193 

Appropriate correction is required. 

Claim Rejections - 35 USC § 103 

5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

6. Claims 1-2, 4-6, 8-19, 21-27, and 29-33 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Aravamudan et al., USPN: 6,584,186 ( hereinafter Aravamudan), in view of 
Reifer et al., USPN: 6,421,727 (hereinafter Reifer). 

As per claim 1, Aravamudan discloses a method comprising: 

retrieving a call service component to a call controller (e.g. servlet 180, applet 175, call 
coordinator 160 - Fig. 1; col. 10, lines 34 to col. 11, line 17; Fig. 4) in response to a network 
carrier turns on a service, corresponding to the call service component, for a particular user area ( 
e.g. PSTN/IP, Softswitch - col. 7, lines 32-44; in response to a request - col. 11, lines 18 to col 
12, line 8 - Note: carrier PSTN and Lucent call coordinator with associated call services read on 
network carrier service for a particular area covered by SIP and SS7 protocol domains spanned 
by a namespace ), the particular area comprising a plurality of users (e.g. server ...protocol, col. 
5, lines 12-20; islands of telephony; namespace to its clients - col. 5, line 62 to col. 6, line 31 - 
Note: a server maintaining a protocol and representing a namespace to be followed by an islands 
of telephony clients via a gateway control reads on particular area covering a plurality of users); 
and 
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using the call service component to support telecommunication traffic to or from a 
gateway under control of the call controller (e.g. col. 12, line 40 to col. 13, line 20; Fig. 4 ); and 

dynamically removing the call service component from the call controller ( e.g. call 
takedown, disconnect command - col 11, lines 45-65). 

But Aravamudan does not explicitly teach downloading of the call service component; 
however, discloses that the applet ("feature applets") can be obtained (loaded and executed by 
the call coordinator) from a network (e.g. loaded ...on the fly ...anywhere from the network ... 
vendor -col. 7, lines 5-18). Hence, the concept of optionally downloading the feature applets 
inside the environment executing the applet is strongly implied. Downloaling of Java 
components to help execute method for servicing end user calls is further taught in Reifer' s 
system using gateway in conjunction of service providers to download code into a controller 
communicating with gateway ( Fig. 9; col. 9, li. 29 to col. 10, line 27). In case Aravamudan does 
not already teach downloading, it would have been obvious for one skill in the art at the time the 
invention was made to implement Aravamudan 5 s controller executing the service component so 
that it have capability to download applet from a external provider or code repository as shown 
by Reifer because this concept of retrieving ready made code, like a applet or servlet, via 
download from remote source was a known concept at the time the invention was made, a 
concept strongly implied by Aravamudan' s above teachings and because it takes advantage of 
Browser utilities to effect the download as evidenced by Reifer, thus optimizing resource usages 
(col. 8, lines 16-40). 

As per claim 2, Aravamudan does not explicitly teach dynamic downloading; but Reifer 
teaches downloading during a browser session as shown in claim 1 ; hence teaches dynamically 
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downloading the call service component when a network carrier turns on a service, 
corresponding to the call service component. Hence, it would have been obvious for one skill in 
the art at the time the invention was made to provide such dynamic loading of call service 
components as taught by Reifer to Aravamudan because of the browser intensive nature of the 
PTSN integration service by Reifer using Java based components also as taught Aravamudan ( 
session col. 8, lines 59-65), which entails a connection activated on the basis of one user's 
request and a session thereof cannot be interrupted for the mere fact of downloading service 
programs, and this is provided via Reifer's teaching. 

As per claim 4, Aravamudan does not explicitly disclose that the call service component 
uses a half-call model that views a call either as an originating or a terminating segment of the 
call; but in view of the 2 sides of a call (e.g. Fig. 1 ; col. 6, lines 10-62 - Note: the use of 
gateways to address each end of a network communication implicitly discloses 2 segments of a 
call, i.e. the source side and a destination side), this half-call model is disclosed. 

As per claim 5, Aravamudan ( see col. 9, lines 8-17) in combination with Reifer (see Fig. 
6-7) discloses or has rendered obvious, according to the rationale as set forth in claim 2 above, 
downloading the call service component from a central repository. 

As per claim 6, Aravamudan does not specifically disclose that each segment of the call 
handles service and access protocols according to a previously downloaded call service 
component with which the segment is associated. But in view of the teaching of the double side 
( re claim 4) of a call establishing as shown via Fig. 1-5, the use of the applet being selected in 
Fig. 4 for handling the segment of the 2-sided call event is implicitly disclosed ( e.g. col. 9, line 
66 to col. line 17). 
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As per claim 8, Aravamudan does not explicitly disclose downloading the call service 
occurs while the call controller is operational and supporting live traffic, the call service being 
downloaded without disrupting the live traffic. But in view of the rationale of claim 2, this 
limitation would have been obvious for the same rationale as set forth therein. 

As per claim 9, Aravamudan discloses an application component for implementing call 
behavior (e.g. Fig. 2-3; col. 8, line 27 to col. 9, line 7 - Note: implementing a call according to a 
tree of events reads on call behavior ). 

As per claim 10, Aravamudan discloses a resource component for providing access to 
telephony resources (col. 9, lines 8-17; col. 10, lines 12-27; col. 1 1, lines 12-17) by an 
application component that implements call behavior. 

As per claim 11, Aravamudan (combined with Reifer) discloses establishing a call 
having an originating segment that uses the call service component downloaded to the call 
controller by virtue of the rationale as set forth in claim 4. 

As per claim 12, Aravamudan does not explicitly disclose that the call service 
component downloaded to the call controller represents a first call type, and wherein the call has 
a terminating segment that represents a different call type while the downloading of components 
has been rendered obvious as in claim 1 . Aravamudan discloses the PTSN islands/namespaces 
specific to a certain protocol in the scheme of the 2 sides on a call ( col. 5, lines 1-20; col. 6, lines 
10-33) and selecting of a component for such context (col. 7, lines 48-59; Fig. 3). Hence the 
limitation of a first call type relating to a downloaded applet and a different call type relating to 
another applet being downloaded is implicitly disclosed or, if not, would have been obvious in 
view of the rationale to download components using the teaching by Reifer as above. 
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As per claim 13, the limitation as to establishing a call having a terminating segment that 
uses the call service component downloaded to the call controller would have been the 
counterpart of the first type of call as mentioned in claim 12; hence would be rejected using the 
same rationale as set forth above. 

As per claim 14, this claim correspond to the counterpart of claim 12 and represent the 
opposite end of the first type of call as recited therein; hence would be rejected using the same 
rationale as set forth above. 

As per claim 15, Aravamudan discloses a telecommunication system comprising: a 
repository of call service components; a call controller; and a gateway under control of the call 
controller ( e.g. server, coordinator - Fig. 1; col. 9, lines 8-17); 

wherein the call controller is configured for retrieving a call service component from the 
repository (Fig. 4; col. 9, lines 8-17) in response to a network carrier turns on a service, 
corresponding to the call service component, for a particular user area ( e.g. PSTN/IP, Softswitch 
- col. 7, lines 32-44; in response to a request - col. 11, lines 18 to col. 12, line 8), the particular 
area comprising a plurality of users (e.g. server ...protocol, col. 5, lines 12-20; islands of 
telephony; namespace to its clients - col. 5, line 62 to col. 6, line 31); 

using the call service component to support telecommunication traffic to or from the 
gateway (e.g. servlet 180, applet 1 75, call coordinator 160- Fig. 1 ; col. 1 0, lines 34 to col. 1 1 , 
line 17; col. 12, line 40 to col. 13, line 20; Fig. 4); and 

dynamically removing the call service component from the call controller ( e.g. call 
takedown, disconnect command - col 11, lines 45-65). 
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But Aravamudan does not explicitly teach downloading of the call service component. 
This limitation has been addressed in claim 1 above. 

As per claim 16, Aravamudan does not explicitly discloses that the call controller is 
configured for dynamically downloading the call service. But this limitation has been addressed 
in claim 2 above. 

As per claims 17, 18, 19, these claims correspond to claims 3-4, 6, respectively; hence 
are rejected with the corresponding rejection as set forth therein. 

As per claim 21, refer to the rationale as set forth in claim 8. 

As per claim 22, this claim recites the limitations of claims 9 and 10; hence is rejected 
with the corresponding cited portions as set forth therein. 

As per claim 23, Aravamudan discloses an article comprising a computer-readable 
medium storing computer-readable instructions for causing a computer system to: 

retrieve a particular call service component from a repository of call service components 
in response to a network carrier turns on a service, corresponding to the call service component, 
for a particular user area, the particular area comprising a plurality of users (e.g. server 
...protocol, col. 5, lines 12-20; islands of telephony; namespace to its clients - col. 5, line 62 to 
col. 6, line 31); and 

use the particular call service component to support telecommunication traffic to or from 
a gateway under control of a call controller; and 

dynamically removing the call service component from the call controller ( e.g. call 
takedown, disconnect command - col 11, lines 45-65); 
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all of these limitations having been rejected with Aravamudan with the corresponding 
cited portions as set forth in claim 1 . 

But Aravamudan does not explicitly teach downloading of the call service component. 
This limitation has been addressed in claim 1 above. 

As per claims 24-26 and 27, 29-31, these claims correspond to claims 2-4, and 6, 8-10, 
respectively; hence are rejected with the corresponding rejection as set forth therein 

As per claim 32, this claim recites the limitations of claim 1 1 and claim 5; hence is 
rejected with the corresponding cited portions as set forth therein. 

As per claim 33, this claim recites the limitations of claim 13 and claim 5; hence is 
rejected with the corresponding cited portions as set forth therein. 

7. Claims 34 and 35 are rejected under 35 U.S.C. 103(a) as being unpatentable over Reifer 
et al., USPN: 6,421,727; further in view Guheen et al., USPN: 6, 957,186 (hereinafter Guheen). 
As per claim 34, Reifer discloses a method comprising: 

dynamically downloading a call service component to a call controller (e.g. Fig. 9; col. 9, 
li. 29 to col. 10, line 27) when a network carrier turns on a service, corresponding to the call 
service component, for a particular user area comprising a plurality of users ( e.g. col. 3, lines 42- 
67 - Note: satellite 'cells', LAC read on a particular area covering plurality of users); and 

using the call service component to support telecommunication traffic to or from a 
gateway under control of the call controller (e.g. MXU, MSQ EIR, MOC, GMS, HLR - col. 3, 
line 30 to col. 4, line 39); 

dynamically removing the call service component from the call controller ( e.g. end of a 
call - col. 4, lines 32-39; deactivation - col. 9 lines 7-14). 
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But Reifer does not explicitly disclose wherein the service component comprises a set of 
core functions surrounded by a wrapper, the set of core functions provides functionality 
associated with the service component, and the wrapper supports the dynamic downloading. In a 
network-based development framework to service requests similar to the SPNet Java-based 
service by Reifer, Guheen discloses Java applet being downloaded analogous to Reifer ( see 
Reifer: col. 9-10) and further discloses a Java Dynamic Management Kit (e.g. col. 18, lines 24- 
46 ) for effecting such applet deployment; and further discloses wrapper to protect reusable code 
being distributed from being affected to/from different sources or insecure transmission 
environments. In view of Reifer' s download scheme in which security via Gateway and Script 
execution ( see Reifer col. 9-10) are used as validation/policy enforcing methods, it would have 
been obvious to protect the downloaded packages so that the scripts be implemented as wrappers 
instead effect the execution of the installation/download according to Guheen' s intention on not 
letting the untrusted environment affect the core code or package content ( see Guheen: col. 19, 
lines 42-56 ). At the time the invention was made, one skill in the art would be motivated to 
enhance Reifer' s Java download and execution framework into a JDMK among other Java tools 
as shown by Guheen because of the many support Java Packages were available at the time to be 
used, particularly when the availability of tools for business request fulfillment as intended by 
Reifer and Guheen would have alleviated resources that would demand code to be rewritten. 

As per claim 35, Reifer discloses a system comprising: 

a network carrier; 

a plurality of media gateways associated with the network carrier (Fig. 1,4); 
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a call controller adapted to control a first one of the media gateways (e.g. MSC 310- Fig. 

3); 

a management system associated with the call controller, wherein the management 
system is adapted to: 

direct dynamic downloading of a service component to the call controller (e.g. Fig. 9; col. 
9, li. 29 to col. 10, line 27) through a Java-based service ( e.g. SPNet service, Fig. 9) when the 
network carrier turns on a new service for the plurality of media gateways (Fig. 1, 4; col. 3, lines 
52-67), and 

control configuration of the first media gateway and the call controller; wherein the call 
controller is adapted to use service component to support telecommunication traffic to or from 
the first media gateway (e.g. MXU, MSC, EIR, MOC, GMS, HLR - col. 3, line 30 to col. 4, line 
39- Note: in conjunction with Switching center MSC, the EIR and GMS with the VLR/HLR 
manage the control for communications between first Home Gateway and other Visiting 
Gateways, thus this reads on both control configuration and call controller) , and 

wherein the management system is adapted to dynamically remove the service 
component when the call controller no longer requires the service component (e.g. end of a call - 
col. 4, lines 32-39; deactivation - col. 9 lines 7-14 ). 

But Reifer does not particularly teach that the service for downloading is a Java Dynamic 
Management Kit (JDMK) framework; nor does Reifer explicitly disclose wherein the service 
component comprises a set of core functions surrounded by a wrapper, the set of core functions 
provides functionality associated with the service component, and the wrapper supports the 
dynamic downloading. In a network-based development framework to service requests similar 



Application/Control Number: 09/843,429 Page 14 

Art Unit: 2193 

to the SPNet Java-based service by Reifer, Guheen discloses Java applet being downloaded 
analogous to Reifer ( see Reifer: col. 9-10) and further discloses a Java Dynamic Management 
Kit (e.g. col. 18, lines 24-46 ) for effecting such applet deployment; and further disclose wrapper 
to protect reusable code being distributed from being affected to/from different sources or 
insecure transmission channel. In view of Reifer' s download scheme in which security via 
Gateway and Script execution ( see Reifer col. 9-10) as validation methods, it would have been 
obvious to protect the downloaded packages so that the scripts be implemented as wrappers 
instead effect the execution of the installation/download according to Guheen' s intention on not 
letting the untrusted environment affect the core code or package content ( see Guheen: col. 19, 
lines 42-56 ). At the time the invention was made, One skill in the art would be motivated to use 
such wrapper code because of the reasons as set forth in claim 34 above. 
8. Claims 7, 20, and 28 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Aravamudan et al. 5 USPN: 6,584,186 and Reifer et al., USPN: 6,421,727, as applied to claims 4, 
18, 23, respectively; further in view Guheen et al., USPN: 6, 957,186. 

As per claim 7, Aravamudan does not disclose a wrapper surrounding a set of core 
functions, wherein the wrapper supports dynamic downloading of the component to the call 
controller. Both Aravamudan and Reifer disclose security controllers and gateways, with Reifer 
further exhibiting security features such as data auditing or rejecting and data package and data 
reformatting by gateways (col. 6, line 1 1 to col. 7, line 53). This security feature is furthered by 
Guheen' s use code wrapper to effect the deployment of Java code being distributed into 
heterogeneous environments wherein the risk of unwanted alteration to the Java package would 
be of concern. Hence, it would have been obvious for one skill in the art at the time the 
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invention was made to implement a wrapper to the process of transmitting service components as 
mentioned by Aravamudan's method so that received components and deployment thereof via 
the well-known gateway concept as by Avaramudan/Reifer can further benefit from 
encapsulation or protection of data via the refitting or format encapsulating of deliverable code 
and control code (like deployment scripts by Reifer) under wrapper format. One skill in the art 
would be motivated to use such wrapper code because of the reasons as set forth in claim 35 
above. 

As per claims 20 and 28, these claim recite the limitations of claim 7; hence are rejected 
with the corresponding cited portions as set forth therein. 

Response to Arguments 
9. Applicant's arguments filed 7/3/2006 have been fully considered but they are not 
persuasive. Following are the Examiner's observations in regard thereto. 

USC §101 Rejection: 

(A) Applicants have submitted that the rejected claims clearly apply to a system in a 
telecommunications system; therefore clearly leading toward statutory subject matter. 
According to the Practical Application requirement, when the claim amounts to a subject matter 
that is not sufficient to convey the realization of a concrete, tangible and useful result, the claim 
is not more than an impractical abstract idea. 

The Federal Circuit has recently applied the practical application test in determining whether the claimed 
subject matter is statutory under 35 U.S.C. § 101. The practical application test requires that a " useful, 
concrete, and tangible result" be accomplished. An "abstract idea" when practically applied is eligible for a 
patent. As a consequence, an invention, which is eligible for patenting under 35 U.S.C. § 101, is in the 
"useful arts" when it is a machine, manufacture, process or composition of matter, which produces a 
concrete, tangible, and useful result. The test for practical application is thus to determine whether the 
claimed invention produces a "useful, concrete and tangible result". 



Application/Control Number: 09/843,429 Page 16 

Art Unit: 2193 

The rejection has shown that there is not sufficient and irrefutable evidence in the 
disclosure to qualify each of the recited elements in the claim( a repository, a controller, a 
gateway) as hardware or a tangible embodiment. That is, these elements do not amount to being 
embodied within a hardware support or tangible executing device, so that when interacting with 
each other in the executing environment of such hardware support, it is reasonable perceived that 
these elements produce a real world result as required by the Practical Application Test. 
Software entities recited in a system claim without being embodied in a hardware or tangible 
device reasonably purported to support the realization of such software execution or actualization 
would amount to non-statutory subject matter. 

The argument is therefore insufficient to overcome the rejection. 

USC 103(a) Rejection: 

(B) Applicants have submitted that Aravamudan's call takedown does not include removing 
any call service components; and that it includes removing those components from anywhere in 
the network as opposed to removing those applets inside the controller as claimed ( Appl. Rmrks, 
pg. 9, last 2 para). The limitation as to 'dynamically removing' has been treated as removing 
runtime components related to the servicing of the call according to the analysis set forth in the 
above CLAIMS OBJECTIONS. Accordingly, the only call service component that can be 
dynamically removed are the very items related to this call service, one of which being the 
connection of the call, because there is not a single support from the Specification as to a clear 
and deliberate implementation describing that the very downloaded — as recited — component is 
removed precisely during this call runtime. The rejection has set forth a context of a coordinator 
working with a tree of commands supported by control files and downloaded applets ( see 
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Aravamudan: col. 7, line 5-59); according to which in response to the event requiring a call 
termination, the applet will support the termination of the call component via execution of said 
commands ( see Aravamudan: col 11, lines 52-65). Hence the 'dynamically removing 5 of call 
related component is fulfilled from the above. 

(C ) Applicants have submitted that Aravamudan's applets can be downloaded and executed 
from anywhere, so that a call takedown would dynamically remove these applets from anywhere. 
There is no such removing of applets 'from anywhere' in Aravamudan nor is there any removing 
of applets in the claim as alleged by Applicants. The coordinator as taught by Aravamudan can 
download on-the-fly applets to execute the commands structure in the controller environment ( 
see Aravamudan col. 7) and terminate the service upon receiving a takedown or on-hook event; 
and this dynamically removal limitation of a service component has been set forth above, based 
on the impropriety analysis of the claim language in the Objection as set forth above. 

Applicant's arguments fail to comply with 37 CFR 1.1 1 1(b) because they amount to a 
general allegation that the claims define a patentable invention without specifically pointing out 
how the language of the claims patentably distinguishes them from the references. 
(D) As for the arguments about Reifer merely ending a call as opposed to removing the 
downloaded JAVA application as proffered by the claim subject matter (Appl. Rmrks, pg. 10, 
top) the disconnect of a call falls under the ambit of the rebut as set forth above using 
Aravamudan's call takedown. The argument is therefore not sufficient to overcome the use of 
Reifer. 

For the sake of argument, even in the event that the Specifications would be read into the 
claims, i.e. allowing the interpretation of the 'dynamically removing' to be such that the 
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controller can decide during runtime and then take away code or API or applets from the 
runtime; this limitation can be treated as either anticipated OR a mere obvious limitation. That 
is, when it is found out that a code is no longer needed for a particular instance of call servicing 
(as in Aravamudan' s tree instance or Reifer 's SPNet session), removing said code - or 
deactivating its execution state — from a call servicing instance (from Aravamudan' s control tree 
or from Reifer' s SPNet browser instance) would be necessary if not a must ( as in inherent 
teaching) to both Reifer and Aravamudan, hence anticipation. Further, as long as the removing 
reads on not using a code for activating or operating the service instance in the sense that a 
component (applet or Java interface) being previously instantiated inside the call activation 
session which is now deactivated — based on the event of a call disconnect as by Aravamudan or 
Reifer- the removal of any such applicable interface code (or deactivation thereof) for that 
particular instance (after the call session ends), would have been obvious for storage reason, and 
this is also well-known. 

(E) Applicants have submitted for claim 34 that neither Guheen nor Reifer discloses this 
limitation (Appl. Rmrks, pg. 10, bottom). The rationale as to using Guheen is not to meet the 
'dynamically removing' limitation. The rationale as to how Guheen in light of Reifer would 
have rendered the 'wrapper' limitation obvious is set forth for specific rationale, against which 
Applicants contend with pointing out a deficiency deemed as being anticipated from section B 
and D above. In response to applicants arguments against the references individually, one 
cannot show nonobviousness by attacking references individually where the rejections are based 
on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In 
re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). 
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If this 'removing' feature is a crucial aspect of the Invention, appropriate description as to 
how it has been implemented should be self-explanatory, deliberate and sufficiently detailed in 
order not to invite what would be considered as unwanted interpretations. And this disclosure 
seems to be deficient at doing this, as addressed above, and this deficiency would not help 
remedy to the lack of clarity in the claim in this regard, so to render it highly patent eligible. 

The arguments for the subject of the remaining claims should fall under the ambit of the 
Examiner's rebut as set forth above in section B, C, and D. 

Therefore, the claims will stand as rejected as established by the Office Action. 

Conclusion 

10. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Tuan A Vu whose telephone number is (272) 272-3735. The examiner can 
normally be reached on 8AM-4:30PM/Mon-Fri. 



Application/Control Number: 09/843,429 



Page 20 



Art Unit: 2193 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kakali Chaki can be reached on (571)272-3719. 

The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571- 



Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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